Description

Issue 02 of the native-product-pages effort: the data layer every native product page consumes — a per-product source adapter returning a normalized, API-shape-agnostic model, plus the two controls that govern it (rollout flag; data-source config). This is reconcile/refactor, not greenfield: the fetchers, zod types, and components already exist; this reorganizes them behind an adapter seam and adds the two config seams.

⚠️ Stacked PR. Base is forecast-date-picker (issue 09), which is itself stacked on native-forecast-reconcile (issue 01, #1121). Linear stack 01 → 09 → 02; this auto-retargets up the stack as the lower PRs merge. Draft until the stack lands.

Related Issues

• .scratch/native-product-pages/issues/02-data-layer-adapter-and-controls.md
• PRD: .scratch/native-product-pages/PRD.md · ADR: "Native product page architecture" (to land as docs/decisions/018-*)
• Depends on 01 (reconciliation) and is stacked on 09 (date picker)

Key Changes

• Normalized model (services/nac/model/forecast.ts) — API-agnostic types the components depend on. Owns the top-level product types (Forecast/Summary/Warning/WarningProduct/…) and reuses the leaf domain enums/types from the v2 wire schema. "No active warning" is plain null, not v2's null-object, so consumers stop special-casing the miss representation (the duplicated toWarningProduct helpers are gone).
• Source adapter (services/nac/sources/) — ForecastSource/WarningSource interfaces, a v2 implementation wrapping the existing fetchers with pure, unit-tested mapV2* mappers, and getForecastSource/getWarningSource resolvers. Components/pages fetch through the adapter, never a raw fetcher.
• Control 2 — data source (sources/config.ts) — per-product v2/v3 selection via code/env config, uniform across tenants, defaulting to v2, with a per-center v3 canary allowlist. Not a Setting. (NAC_{FORECAST,WARNING}_SOURCE, NAC_{FORECAST,WARNING}_V3_CANARY_CENTERS.)
• Control 1 — rollout — Settings.useNativeForecasts becomes a per-product nativeProducts: { forecast, warning } group; new getNativeProductFlag(center, product) reader. Per-product (not all-or-nothing) so a center can go native on forecast while later products stay on the widget.
• Call sites (NativeForecastPage, AllZonesForecast, both [zone] routes) wired to the adapter; all forecast components repointed to the model.

How to test

• pnpm tsc, pnpm lint, pnpm test (includes new v2→model mapper tests in __tests__/server/nacSourceMappers.server.test.ts).
• Flip a center's nativeProducts.forecast in Settings → native forecast page renders; off → legacy widget.
• Data source defaults to v2; setting NAC_FORECAST_SOURCE=v3 (or the canary allowlist) currently throws by design until the v3 source is built.

Migration Explanation

20260622_223300_native_products_flag generalizes the single use_native_forecasts boolean into the native_products_forecast / native_products_warning columns. It adds both columns, backfills both from the old value (so a center already on the native forecast page — warning banner included — is unchanged), then drops the old column. Verified on a dev.db copy: a row with the old flag set retains both new flags; data preserved. migrate:check flags the ALTER/DROP for review (expected for any schema migration); the drop is intentional and data-preserving.

Future enhancements / Questions

• getUseNativeForecasts is kept as a now-unused thin wrapper over getNativeProductFlag — can be deleted.
• The v3 source/mapper is deliberately not built (PRD risk: v3 deployment unverified). The seam is in place; flipping a product to v3 is a one-line config change once v3 is confirmed deployed.
• Archive/by-id stay view-helpers (not under the adapter), feeding the model props via structural compatibility (wire ≡ model for v2).

🤖 Generated with Claude Code